Skip to content

[Proposal] add is identical methods to concrete types #1383

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
wants to merge 2 commits into
base: main
Choose a base branch
from

Conversation

vanvoorden
Copy link
Contributor

Many types in Foundation are “copy-on-write” data structures. These types present as value types, but can leverage a reference to some shared state to optimize for performance. When we copy this value we copy a reference to shared storage. If we perform a mutation on a copy we can preserve value semantics by copying the storage reference to a unique value before we write our mutation: we “copy” on “write”.

This means that many types in Foundation already have some private reference that can be checked in constant-time to determine if two values are identical. Because these types copy before writing, two values that are identical by their shared storage must be equal by value.

@vanvoorden vanvoorden marked this pull request as draft June 26, 2025 23:41
@vanvoorden vanvoorden marked this pull request as ready for review June 26, 2025 23:44
@vanvoorden vanvoorden changed the title [Evolution][WIP][DNM] add is identical methods to concrete types [Evolution] add is identical methods to concrete types Jun 26, 2025
@vanvoorden vanvoorden changed the title [Evolution] add is identical methods to concrete types [Proposal] add is identical methods to concrete types Jun 27, 2025
@vanvoorden
Copy link
Contributor Author

@parkera Would you have any opinions about running this proposal concurrently with our proposal to add these methods to concrete types from stdlib?1 Can you think of examples in the past where one evolution proposal opened on stdlib and another proposal on Foundation covered similar designs but just focused on different concrete types?

I'm thinking there might be interesting feedback in one proposal review that we might want to feed back and influence the other proposal review. Or it might be easier to start with stdlib and then consider that completed design the "prior art" for a later proposal on Foundation.

Hmm… any ideas about that?

Footnotes

  1. https://github.com/swiftlang/swift-evolution/pull/2875

@parkera
Copy link
Contributor

parkera commented Jul 18, 2025

If we run a proposal through swift-evolution and it includes extensions to Foundation API, and the Foundation workgroup doesn't object for some reason, then we can consider it accepted.

@parkera
Copy link
Contributor

parkera commented Jul 18, 2025

Maybe we just give interested parties a heads up by creating a thread in the Foundation section, in case they don't follow the other evolution threads on the forums.

@vanvoorden
Copy link
Contributor Author

@parkera Hmm… so it sounds like maybe the idea here is:

  • Wait for an LSG review manager to pick up the stdlib proposal.
  • Ask the LSG review manager if they are ok with adding these Foundation changes in the stdlib proposal.
  • Show the final draft to the Foundation workgroup to ask if they are ok with these changes going along with a stdlib proposal.

For now… I'm still blocked waiting on an LSG review manager for the stdlib proposal. But once that is ready to schedule for a review we can discuss unifying them back together? Does that sounds about right? Thanks!

@itingliu
Copy link
Contributor

itingliu commented Jul 22, 2025

Either way I can see if the swift-evolution is accepted, I imagine adding it to AttributedString will be fairly straightforward because we generally let AttributedString follow what String has. But I'm not sure if we've had such a clear parallel with Data with a stdlib type so perhaps we'll get more feedback in this type.

I see that the swift-evolution proposal doesn't currently include Foundation types. If you decide to continue with that version, when it's in review, you can post a pitch about these two proposals for adding it to Data and AttributedString in the foundation forum, and we can move it into the abbreviated review right away so it runs the same time as the swift-evolution one, so we can get feedback together. The downside is that you'll have to juggle the two review threads at the same time.

If you want to add a section in the swift-evolution proposal to cover AttributedString and Data, then I think a short message in foundation forums to bring people's attention to the other review thread would be nice. I (or anyone on the foundation workgroup) would also be happy to direct people's attention there if you prefer us to do that. The swift-evolution review is sufficient for foundation workgroup for the purpose of getting feedback, so we don't need another review for swift-foundation. The downside is the review will likely be more complicated since it'd include more types.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants